Introduction: Cash Register Clock (VFD Display)
My journey through reverse engineering a slightly used cash register display.
After getting everything working, I'm demonstrating it as a clock, although my future plans for the display are not really know at this time...
Step 1: Background
The company I work for has electronic recycling bin that is a grave yard of discarded electronics. Although the electronics are not longer needed, that does not mean that they are not functional. I sometimes pass by these bins and things catch my eye. On this occasion, the bins contained three fully functional IBM cash registers. Although they had been damaged when hoisted into the bins, I noticed that the register displays were intact. I decided to harvest all three of the displays and see if I could put them to some future use. Since I had time, I also was able to unwind the wiring harnesses from the registers.
Later, after disassembling the case, I was able to pull the full raw display PCB out and find the make and model. Make: Futaba Corp Model: M202MD10C. Doing a little online searching I found that Futaba makes quite a few models of displays and this model was a bit dated. Through the Futaba web site I was able to register and download similar data sheets, but not the exact data sheet for this unit.
The newer models would run on 5 volts and some even sport a USB interface. Other models were designed to connect directly to some bus (computer bus?) and ran at 12 volts. I suspected the this was a 12 Volt model but there was really only one way to verify that.
Looking at the data sheet, I found that it used a ASCII code for characters and some additional codes for enabling different functions on the unit. That was promising. If I could get this connected and understand the communication method then I could probably just send it ASCII over a serial terminal program.
Step 2: Wiring Harness
I didn’t want to solder a bunch of leads to the board and fortunately I had grabbed the wiring harness. The harness connected to the register computer using a DB9 type serial connector. The other end connected to the VFD used a 4 lead phone style jack.
Ok, 9 leads input, 4 leads used in the connection to the VFD. Some of the DB9 leads aren’t used. Using a continuity DMM I mapped out the DB9 pins to the pins on the phone jack header.
Also following the PCB traces, I was able to identify the likely voltage pin as well as the ground pin. The other two pins I wasn’t sure of, but suspected that they were serial TX and RX pins.
Step 3: Power Up.
Being one to throw caution to the wind and pay the penalty, I decided to hook up and power it up through my trusty adjustable power supply. Limiting the amperage and start with 7 Volts of course.
Nothing at 7 Volts and no smoke. Good start. I verified that the voltage was reaching the board in places where I though it should reach. I increased the Voltage to 10 Volts and was greeted with a cursor bar in the first column on the display! That looks really normal.
Step 4: Serial Communication Identification
The next step was to wire up the serial Tx and Rx pins and see if I could send something to the display using my FTDI Friend.
Not knowing which lines were Tx and Rx, randomly attached them to the FTDI Friend and tried to send a few characters. Ok, didn’t get anything so I flipped them around and tried again. Hey! Success. Key presses were being presented on the VFD display… Ok, not the exact key presses, but presses. So I started try and decipher the relationship between what I was seeing and the keys I was pressing.
This is about the time I realized that my power supply fan was humming a bit more than usual and there was a faint odor of smoke in the air. I shut everything down and did a little finger temperature testing to see if I could find the source of the undesired heat.
Nothing coming from the display board and the header was fine.
The heat was coming from my FTDI friend. Interesting… Now that I knew which line was the Rx line, I left it attached and pulled what I thought was the Tx line. Powering up again and used my DMM to check the voltage on the unknown line. 7 Volts. Not sure why but there is 7 Volts returning back through the header to the source. I haven’t figured that out exactly and I don’t see a reference to this in the newer specs documents… Maybe some kind of indication that there is something plugged in? At this point I am going to assume that it’s not useful to me and move on with just the Rx line hooked up.
Ok, so now I know that there are 4 lines, two for ground and power, 1 for Rx and one returning 7 Volts.
Fortunately I was able to catch the error before I actually injured my FTDI friend. It appears to be working as normal.
Step 5: Roadblock
Now that I had the power and serial connection deciphered, I could turn my attention to getting the VFD to actually display the characters that I wanted it to display.
I hit a wall here.
I tried several approaches to get this worked out.
Thinking that there might be some some kind conversion problem in my initial Perl program, I resorted to writing the serial communication in C. Just so I could make sure that only the characters I wanted to send were being sent.
I verified that I hadn’t fried my FTDI friend by hooking two together to confirm that I had a good serial signal.
With some suggestions from Google+ members on the “Makers, hackers, artists & engineers” group, I investigated the microcontroller that appeared to be driving the functions needed to run this kind of display.
Step 6: Snoop Soldering
The micro controller running the show here is an NXP P87C54X2BBD.
A quick google search lead me to the PDF Datasheet from philips and I was able to find the pinout for this package. By looking at the PCB, I could see that there were not that many pins used on this particular package.
When I started getting desperate, I decided to attach a wire to the RxD pin and see what was being sent to the controller. I hooked up a second FTDI Friend to this pin and ground and sent characters over the first FTDI Friend. It turns out that the characters that were being displayed were exactly the same as those read at my wire patch. In fact I was able to send characters directly to the Microcontroller through this wire patch and the display was suddenly working! So the problem existed somewhere between the wire patch and the wiring harness. Using a Oscilloscope, I was able to compare the two digital signals and determine that the signal reaching the micro controller was inverse the expected digital signal.
Ah, The signal is inverted. So let’s try uninviting it and see what we get.
For that I used a NPN transistor to give me an inverted digital signal that was fed in through the wiring harness.
Step 7: TTL Serial Inverter
Here is the schematic that I ended up building for the wiring harness.
Very simple, no I’m not an EE so I’m sure there’s something better out there, but this worked.
I soldered it all together onto a very small bit of PCB board.
I have upgraded the schematic at http://circuits.io. Here is the link:
Step 8: Makings of a Simple Clock
Just to get something “MADE”. I made a quick clock program to use the display. This is Perl code using Linux /dev/ttyUSB0 serial interface.
use strict;
use FileHandle;
use constant {
DIM => 0x04, ## Dimming
DP => 0x10, ## Display Position
CLR => 0x0D, ## Clear
ALD=>0x0F, ## All Display (test mode)
BLK=>0x0A, ## Blinking (doesn't appear to work)
SCR=>0x0B, ## Scroll (not working either..)
};
##usb serial device (FTDIFriend from adafruit.)
my $deviceFn = '/dev/ttyUSB0';
sub dateString
{
my ($sec, $min, $hr, $day, $mon, $year) = localtime;
return sprintf("%04d/%02d/%02d",
1900 + $year, $mon+1, $day);
}
sub timeString
{
my ($sec, $min, $hr) = localtime;
return sprintf("%02d:%02d:%02d", $hr, $min, $sec);
}
my $clockTemplate = " %s\n %s";
my $fh = new FileHandle;
$fh->open(">" . $deviceFn) || die "couldn't open serial port";
$fh->autoflush();
my @dateCursor = (DP, 0x05);
my @timeCursor = (DP, 0x19);
my @homeCursor = (DP, 0x05);
##update the time every second...
##update the date less frequently
my $dateTrigger = 0;
while(1)
{
if($dateTrigger == 20)
{
$fh->print(pack('C*', @dateCursor));
$fh->print(dateString());
$dateTrigger = 0;
}
$dateTrigger++;
$fh->print(pack('C*', @timeCursor));
$fh->print(timeString());
$fh->print(pack('C*', @homeCursor));
sleep(1);
}
